To reduce the amount of cfg in this file, I would suggest something like this:

#[cfg_attr(not(all(target_os = "linux", any(target_arch = "x86_64", ...), path = "trace/stub.rs")]
mod trace;

and then the stub.rs file contains just a bunch of empty functions and dummy type aliases so that to the outside, it looks like all the same functions and types exist.

Let's just keep using that allocator on all Linux targets, no harm in that.

It's not very reassuring if the code says "might be desired behavior".^^

It's kind of odd though that we would do this for "Linux without ptrace", but not do it on macos...

Outside of many-seeds performance-sensitive scenarios, I find it hard to imagine when we wouldn't be okay with this blocking. I do recall running into a concrete case where this was desired; the ptr_write_access test will write to statics, so performing it in in many-seeds mode without the tracing caused it to randomly segfault (but it was fine with, as it forced the threads to take turns)

Yeah, I'm fine with the blocking.

But then the do_ffi implementation in trace/stub.rs should also do it to ensure feature parity. :)

Is there any citation or so you can give for this?
Seems pretty important that we don't get this wrong.^^

I can add a comment explaining the rationale, but there isn't really a canonical set of flags to use for this that I know of. WEXITED makes sure we actually kill the child process when it exits instead of leaving it as a zombie, and WUNTRACED is mostly helpful at the very start before we've ptraced

Uh, I think you misunderstood my comment.^^ It refers to this:

The largest arm64 simd instruction operates on 16 bytes.

oh! oops. Yes, I'll add a citation

Can it actually happen that the same operation is both a read and a write? Is that used for instance for atomic fetch-and-add and operations like that?

I don't know which ops exactly (I know on arm64 there's an explicit swap register with memory op for example), but yes there are x86 ops that do both. The write isn't always done on all ops; per iced which I was using before and is explicitly x86-focused so I'll trust as a source, the possible options are Read, CondRead, Write, CondWrite, ReadWrite, and ReadCondWrite. Since this only triggers when an access occurs, we can treat CondRead and CondWrite the same as their normal versions bc we know the condition was met, and putting a write after the read on a ReadCondWrite if the condition wasn't met is still fine in the sense that we don't lose information, just might accidentally mark uninit stuff as init.

We could maybe get around this with another mempr_* function so that instead we first set perms to read instead of RW, and if it retriggers a segfault we know for sure the write happens, but that might add a good bit of code complexity. It's an idea I've had for a bit though and plan on implementing at some point.

Oh so these events are still approximate, we don't know if both a read and a write actually happened? Good to know, we have to keep that in mind when interpreting the events. That reduces the benefit of having precise range information...

Well, that's only on the RCW events. I can add a boolean is_certain field on the write and if it's false we double-check that the allocation it's writing to is mutable first, but that will be a very rare edge case

It is UB to run compare_exchange on an immutable allocation even if it ends up not writing anything. So that particular check should be fine, if it only affects such atomic operations.

I'll pour over the iced source later then, just to see which instructions that flag is set for. Ty!